[github-actions]: Adopt durable execution CI v0.3.0 - #658

Codex AI review

Found one high-severity CI lifecycle issue: AI-created or AI-updated PR heads can bypass validation for the new SHA.

Reviewed commit 6ce3d43484b421540c952c4110663a1287d29c74. Workflow run

Claude AI review

No confirmed, actionable defects found in this PR. It is limited to GitHub Actions workflow YAML; the reusable workflows it delegates to are pinned at an immutable first-party SHA and are outside the diff, so their input contracts and internal command/authorization gating cannot be verified here.

Verified and correct in-diff:

• SHA-pin consistency: ai-pr-review.yml, issue-triage.yml, and notify.yml are moved to 8de63fa646c1b7b778829126cf53b7874074795e, matching the already-updated stale-issue-closer.yml — all four shared-CI callers now agree.
• workflow_run wiring: ai-pr-review-address-continuation.yml references workflows: [AI PR Review Address], which exactly matches the name: of the new ai-pr-review-address.yml, so the continuation will fire. Its if correctly scopes to workflow_run.event == 'pull_request_review_comment' && conclusion == 'success', so it does not double-run for issue_comment/workflow_dispatch paths (which the address workflow handles directly).
• Event routing: In ai-pr-review-address.yml, the read-only intake job (pull_request_review_comment, no secrets) vs. the privileged address job (issue_comment/workflow_dispatch) split is coherent — the privileged review-comment path is deferred to the workflow_run continuation running from the default branch, which is the correct hardening pattern.
• Expression guards: ${{ inputs['issue-number'] || '' }}, ${{ inputs['pull-request-number'] || '' }}, and format('{0}', github.event.workflow_run.id || '') all degrade safely to empty strings when the field is absent (e.g., non-dispatch triggers). run_attempt/id are valid workflow_run payload fields. The folded (>-) if blocks evaluate correctly (newlines are treated as whitespace by the Actions expression parser).
• Top-level permissions: {} with per-job grants is preserved consistently.

Residual risk (not confirmable from this diff; recommend a maintainer confirm against the reusable workflow definitions):

1. ai-pr-review.yml escalates contents: read → contents: write while running under pull_request_target (plus the added issue_comment/pull_request_review* triggers) with secrets: inherit. This is the canonical pull_request_target privilege-escalation surface. It is presumably intentional and safe because the reusable workflow is first-party and pinned, but confirm the review workflow genuinely needs write-to-contents and never executes untrusted PR-head code with that token.
2. notify.yml drops models: read. This is only correct if the v0.3.0 notify.yml no longer uses GitHub Models; otherwise notifications will fail at runtime. Confirm the pinned reusable workflow no longer requires that scope.
3. ai-pr-review.yml's single job has no if: gate, so it invokes the reusable workflow on every added event (including pull_request_review_comment: deleted and pull_request_review: dismissed) and every issue_comment; and ai-issue-implementation.yml's implement job has no command/if gate on issue_comment. These rely entirely on the reusable workflows to filter/no-op, which is noisier than the explicitly gated ai-pr-review-address.yml. Confirm the reusable workflows short-circuit non-matching events (and consider a concurrency group) to avoid redundant runs.
4. The intake job in ai-pr-review-address.yml calls the reusable workflow without secrets: inherit or a with: block; this is only correct if pull-request-number is an optional input on that reusable workflow and the intake path needs no secrets.

There are no code/unit-test changes in this PR, so no test coverage is applicable; the residual risk is purely in the unverifiable reusable-workflow contracts noted above.

Reviewed commit 6ce3d43484b421540c952c4110663a1287d29c74. Workflow run